1. Field of the Invention
The present invention relates to a method and apparatus for performing distributed object calls using proxies on the client side and memory allocation on the server side. Specifically, the method involves the creation of a proxy handle data structure to be associated with a particular object and its associated object reference. On the client side, object calls to the associated object are then made using the proxy handle, thus allowing multiple calls to the same object and eliminating the need to perform certain initialization functions each time the call is made. On the server side, the server allocates memory in a platform-independent manner.
2. Background
Distributed object computing combines the concepts of distributed computing and object-oriented computing. Distributed computing consists of two or more pieces of software sharing information with each other. These two pieces of software could be running on the same computer or on different computers connected to a common network. Most distributed computing is based on a client/server mode. With the client/server model, two major types of software are used: client software, which requests the information or service, and server software, which provides or implements the information or service.
Object-oriented computing is based upon the object model where pieces of code called xe2x80x9cobjectsxe2x80x9dxe2x80x94often abstracted from real objects in the real worldxe2x80x94contain data (called xe2x80x9cattributesxe2x80x9d in object-oriented programming parlance) and may have actions (also known as xe2x80x9coperationsxe2x80x9d) performed on it. An object is defined by its interface (or xe2x80x9cclassxe2x80x9d in C++ parlance). The interface defines the characteristics and behavior of a kind of object, including the operations that can be performed on objects of that interface and the parameters to each operation. A specific instance of an object is identified within a distributed object system by a unique identifier called an object reference.
In a distributed object system, a client application sends a request (or xe2x80x9cobject callxe2x80x9d) to a server application. The request contains an indication of the operation to be performed on a specific object, the parameters to that operation, the object reference for that object, and a mechanism to return error information (or xe2x80x9cexception informationxe2x80x9d) about the success or failure of a request. The server application receives the request and carries out the request via a server xe2x80x9cimplementation.xe2x80x9d The implementation satisfies the client""s request for an operation on a specific object. The implementation includes one or more methods, which are the portions of code in the server application that actually do the work requested of the implementation. If the implementation is carried out successfully, the server application may return a response to the client. The server application may also return exception information.
To standardize distributed object systems, the Object Management Group (xe2x80x9cOMGxe2x80x9d), a consortium of computer software companies, proposed the Common Object Request Broker Architecture (xe2x80x9cCORBAxe2x80x9d). Under the CORBA standard, an Object Request Broker (xe2x80x9cORBxe2x80x9d) provides a communication hub for all objects in the system passing the request to the server and returning the response to the client. Commercial ORB""s are known in the art and a common type is IBM""s System Object Model (xe2x80x9cSOMxe2x80x9d). On the client side, the ORB handles requests for the invocation of a method and the related selection of servers and methods. When a client application sends a request to the ORB for a method to be performed on an object, the ORB validates the arguments contained in the request against the interface for that object and dispatches the request to the server, starting it if necessary. On the server side, the ORB uses information in the request to determine the best implementation to satisfy the request. This information includes the operation the client is requesting, what type of object the operation is being performed on, and any additional information stored for the request. In addition, the server-side ORB validates each request and its arguments. The ORB is also responsible for transmitting the response back to the client.
Both the client application and the server application must have information about the available interfaces, including the objects and operations that can be performed on those objects. To facilitate the common sharing of interface definitions, OMG proposed the Interface Definition Language (xe2x80x9cIDLxe2x80x9d). IDL is a definition language (not a programming language) that is used to describe an object""s interface; that is, the characteristics and behavior of a kind of object, including the operations that can be performed on those objects.
IDL is designed to be used in distributed object systems implementing OMG""s CORBA Revision 2.0 specification, which is incorporated by reference herein. In a typical system implementing the CORBA specification, interface definitions are written in an IDL-defined source file (also known as a xe2x80x9ctranslation unitxe2x80x9d). The source file is compiled by an IDL compiler that generates programming-language-specific files, including client stub files, server stub files, and header files. Client stub files are language-specific mappings of IDL operation definitions for an object type into procedural routines, one for each operation. When compiled by a language-specific compiler and linked into a client application, the stub routines may be called by the client application to invoke a request. Similarly, the server stub files are language-specific mappings of IDL operation definitions for an object type (defined by an interface) into procedural routines. When compiled and linked into a server application, the server application can call these routines when a corresponding request arrives. Header files are compiled and linked into client and server applications and are used to define common data types and structures.
In a system implementing the CORBA specification, object calls are made by calling the appropriate client stub function. The parameters to these stub functions typically include the input parameters for the requested operation and the object reference of the object. The CORBA specification, however, has certain performance-related drawbacks. First, each time an object is called, certain configuration operations must be performed. For instance, the object must be validated to ensure its existence. In addition, memory (or another resource) is often allocated for the call. The interface must be determined. Finally, transport of the call is prepared (e.g., opening files, preparing sockets, etc. . . . ). Performing each of these operations prior to each object call can be very time-consuming. In a time-critical application, the overhead associated with each object call can significantly affect performance.
Further, on the server side, performance is affected by the improper allocation and deallocation of memory (xe2x80x9cgarbage collectionxe2x80x9d). In many distributed object systems, memory can be allocated for the implementation of an object call. Once the implementation has been performed and the server responds to the call, however, memory is not automatically deallocated. This failure to deallocate memory leads to wasted resources and, therefore, slower performances. In addition, the failure to remove pointers or addresses pointed to by pointers can lead to larger problems, such as system errors and application shutdowns.
Certain systems have attempted to use garbage collection in the implementation of object calls. Those systems, however, use platform-specific methods for deallocating memory. Thus, code portability is often sacrificed in favor of proper memory allocation and deallocation.
Accordingly, a need exists for a method for improving object call performance by eliminating the need to configure an object call each time the same object is called.
Further, a need exists for a platform-independent method for improving object call performance by allocating and deallocating memory during object implementation.
The present invention provides a method and apparatus for performing object calls that improves performance by eliminating the need to configure an object call each time the same object is called. The present invention also improves object call performance by allocating and deallocating memory during object implementation.
More particularly, the present invention is directed to a method for calling an object via a generated stub function within a client application to a server application. The call is performed by first obtaining an object reference that refers to the object. Next, the object reference is used to create a proxy handle to represent the object in calls to the object. The object is then called via the stub function. The stub function is passed the proxy handle, an input parameter of an operation to be performed on the object, an output parameter of the operation, and exception information. The object is then implemented via a method function in the server application. The server application responds to the caller and completes the call. The proxy handle may be used again for a subsequent call to the same object. Once the final object call has been made, the proxy handle is destroyed.
The creation of the proxy handle automatically allocates resources for the object call. When the proxy handle is destroyed, those resources are freed. Moreover, since the proxy handle can be used for multiple calls to the same object, the client application is not required to perform any initialization that may have been performed during the previous object calls. For instance, object validation, file opening, and socket preparation are events that are commonly performed during each object call. These initialization events may be placed in a time-critical portion of the application to save resources. Finally, multiple proxy handles may be used for the same object to force users to comply with certain requirements before implementing a particular feature of an object. In this manner, files and similar objects may be pseudo-encrypted.
In an alternative embodiment, resources may be allocated and deallocated during the actual implementation of the object. In this embodiment, the method function in the server application calls a function to allocate the appropriate resources. The function returns a pointer to memory that has been allocated on the heap in the server computer. Upon completion of the method function, the memory is automatically deallocated. Automatic deallocation of memory reduces the likelihood of random pointers and memory leaks that can often occur during the implementation of an object.